Мы много пишем про растянутые кластеры VMware vSAN Stretched Clusters для онпремизной инфраструктуры VMware vSphere, но не особо затрагивали тему растянутых кластеров в публичных облаках. В частности, в инфраструктуре VMware Cloud on AWS можно создавать такие кластеры, работающие на уровне зон доступности (Availability Zones).

Облачные администраторы знают, что публичное облако AWS разделено на регионы (Regions), в рамках которых есть зоны доступности (Availability Zones, AZ), представляющие собой домены отказа (аналогичные таковым в vSAN). То есть если произойдет сбой (что довольно маловероятно), он затронет сервисы только одной зоны доступности, остальные AZ этого региона продолжат нормально функционировать.

Сама Amazon рекомендует дублировать критичные сервисы на уровне разных зон доступности, а с помощью растянутых кластеров VMware vSAN можно сделать полноценную задублированную среду на уровне AZ в рамках одного региона с компонентом Witness для защиты от ситуации Split-brain, когда будет разорвана коммуникация между зонами:

Для такой конфигурации вам потребуется создать SDDC с поддержкой Stretched Cluster, который создается на этапе настройки SDDC на платформе VMC on AWS. Надо понимать, что при развертывании SDDC можно задать тип кластера Standard или Stretched, который уже нельзя будет поменять в дальнейшем.

Пользователь задает AWS Region, тип хоста, имя SDDC и число хостов, которые он хочет развернуть. Далее администратор выбирает аккаунт AWS и настраивает VPC-подсеть, привязывая ее к логической сети для рабочих нагрузок в аккаунте. Нужно выбрать 2 подсети для обслуживания двух зон доступности. Первая устанавливается для preferred-площадки vSAN, а вторая помечается как сеть для "non-preferred" сайта.

После создания кластера, когда вы зайдете в инстанс Multi-AZ SDDC vCenter вы увидите растянутый кластер vSAN с одинаковым числом узлов на каждой из AZ и один компонент Witness, находящийся за пределами данных AZ.

Такая конфигурация работает как Active-Active, то есть вы можете помещать производственные виртуальные машины в каждую из зон, но вам нельзя будет использовать более 50% дисковой емкости для каждой из облачных площадок.

Конечно же, нужно позаботиться и о защите виртуальных машин как на уровне площадки, так и на уровне растянутого кластера. Лучше всего использовать политику хранения "Dual site mirroring (stretched cluster)" на уровне ВМ. В этом случае при сбое виртуальной машины в рамках одной зоны доступности она будет автоматически перезапущена в другой AZ с помощью механизма VMware HA.

Также администратору надо контролировать физическое размещение виртуальных машин по площадкам, а также политику Failures to tolerate (FTT):

Конечно же, не все виртуальные машины нужно реплицировать между площадками - иначе вы просто разоритесь на оплату сервисов VMConAWS. Администратор должен выставить правила site affinity rules, которые определяют, какие машины будут реплицироваться, а какие нет. Делается это с помощью движка политик storage policy-based management (SPBM) для ВМ и их VMDK-дисков: 

Также более подробно обо всем этом вы можете почитать в статьях vSAN Stretched Cluster Guide и VMware Cloud on AWS: Stretched Clusters.

Продолжаем рассказывать вам о продуктах компании StarWind, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Сегодня мы расскажем о бесплатной утилите V2V Converter / P2V Migrator, которая позволяет делать три важных для администратора вещи...

Компания VMware продолжает поддерживать своих облачных партнеров, которые предлагают своим пользователям услуги аренды виртуальных машин. Мы уже писали о новостях для сервис-провайдеров на прошедшей конференции VMworld 2021, а сегодня расскажем еще об одном анонсе - возможность предложения пользователям услуг Tanzu Standard Edition.

Начиная с 25 ноября, провайдеры получили доступ к VMware Tanzu Standard - платформе, которая позволяет разработчикам развертывать и поддерживать свою инфраструктуру контейнеризованных приложений в кластерах Kubernetes. Теперь это возможно и в облаке посредством интеграции решений VMware Tanzu Standard и VMware Cloud Director (пока поддерживается версия 10.2), что позволяет создать инфраструктуру Kubernetes as-a-Service (KaaS) для мультиоблачных сред.

Теперь сервис-провайдеры имеют выбор между инфраструктурой Tanzu Kubernetes Grid, построенной на собственном дистрибутиве Kubernetes от VMware, и полностью интегрированном сервисе на платформе vSphere. Управлять всем этим можно через консоль Tanzu Mission Control.

Вот какие сервисы теперь могут предлагать провайдеры своим клиентам:

• Создание кластеров K8s
  • Развертывание кластеров
  • Служба VMware Storage service для окружений разработчиков
  • Библиотека контента (Content library) для версий Kubernetes
  • Сетевой сервис для K8s-кластеров, включая балансировку нагрузки (NSX ALB Basic), сервисы NAT и другое
  • Плагин для интерфейса Antrea Container Networking Interface (CNI)
  • Сервисы обслуживания жизненного цикла через Cluster API
• Операции с кластерами K8s
  • Привязка и управление CNCF-совместимыми кластерами K8s
  • Централизованный доступ и управление политиками
  • Служба vSphere Pod Service
  • Служба Image Registry на базе Harbor для управления версиями в контейнерном окружении
  • Возможности мониторинга состояния рабочих нагрузок через Fluent Bit, а также Prometheus и Grafana для мониторинга самой платформы
  • Управление на базе vCenter
  • Резервное копирование и восстановление пространств имен, а также запланированный бэкап
  • Возможности аудита системы и произошедших событий, включая срез кластера по производительности
  • Возможность загрузить opensource-пакеты для мониторинга через Fluent Bit, а также службу image registry через Harbor и Calico CNI

Больше интересного о решении Tanzu Standard Edition для сервис-провайдеров можно узнать на следующих ресурсах:

• Tanzu Standard Solution Brief
• VMware Tanzu Editions – Tanzu Standard
• VMware Developer Ready Cloud
• VMware Tanzu Blog

Аналитическая компания Gartner выпустила отчет "2021 Magic Quadrant for Hyperconverged Infrastructure Software", отражающий ситуацию на рынке гиперконвергентной инфраструктуры. Это такая инфраструктура, где все ее вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Компания VMware заняла в этом квадранте место лидера (надо отметить, что учитывались не только онпремизные, но и облачные HCI-инициативы), расположившись рядом со своим главным конкурентом в этой сфере - компанией Nutanix:

Может показаться, что многие вендоры гиперконвергентных решений просто сошли с дистанции за пару лет. Давайте взглянем на тот же квадрант за 2018 год, где были решения от HPE, Dell EMC и Cisco:

Но дело совсем не в этом, просто поменялась методика определения игроков - теперь в квадрант добавляют только тех вендоров, которые предоставляют интегрированное решение для гиперконвергентной инфраструктуры на базе серверов, а значит оттуда убрали Cisco, Dell EMC, HPE, Huawei и Red Hat. Более подробно об этом вы можете почитать здесь.

VMware занимает место в квадрате лидеров заслуженно, несмотря на то, что не занимается производством аппаратного обеспечения. Очевидно, что в гиперконвергентной среде сложно построить инфраструктуру на базе одного вендора, поэтому в любом случае нужны решения для виртуализации и агрегации ресурсов.

Приятно также видеть среди ведущих HCI-производителей компанию StarWind Software, флагманским продуктом которой в HCI-сфере является программно-аппаратное решение StarWind HyperConverged Appliance (HCA), о котором мы писали вот тут.

Скачать отчет 2021 Magic Quadrant for Hyperconverged Infrastructure Software можно по этой ссылке.

Как все из вас знают, не так давно компания VMware выпустила обновление своей серверной платформы виртуализации vSphere 7 Update 3. Мы писали также о нововведениях в отношении хранилищ, обновлении 3a, новых возможностях продукта vSAN 7 U3 и обновлениях vCenter и vSphere Client.

Сегодня мы поговорим об улучшениях в плане производительности платформы VMware vSphere 7 Update 3, о которых рассказано в обновившемся недавно документе "What’s New in Performance for VMware vSphere 7?". О похожем документе о производительности платформы vSphere 7 Update 2 мы писали в начале осени тут.

Давайте посмотрим, что нового в vSphere 7 U3 в плане производительности:

1. Масштабируемость виртуальных машин

Теперь максимальные параметры ВМ, доступных в vSphere выглядят так:

2. Оптимизации рабочих нагрузок, чувствительных к задержкам

Гипервизор VMware ESXi был еще больше оптимизирован, чтобы быстрее исполнять приложения, чувствительные ко времени отклика и задержкам (ultra-low-latency applications), уменьшены jitter и interference для приложений реального времени. Для этого было сделано множество оптимизаций в плане обработки прерываний. Чтобы воспользоваться этой функцией (low-latency mode) ее надо включить в BIOS машины.

3. Технология vSphere Memory Monitoring and Remediation (vMMR)

Размер памяти DRAM влияет на 50-60% стоимости самого сервера. При этом 1TB DRAM - это уже 75% этой стоимости. Поэтому VMware давно борется с этим, и одна из возможных оптимизаций здесь - использование Intel Optane Persistent Memory Mode, когда железо использует DRAM как кэш и представляет PMem как основную память системы. PMem более дешевая технология, но имеет побольше задержки (latency).

С помощью vSphere Memory Monitoring and Remediation (vMMR) можно следить за работой памяти в режиме Intel PMem Memory Mode и получать алерты когда ESXi исчерпывает память DRAM, что может привести к падению производительности сервера.

4. NVMe over TCP/IP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании при поддержании высокого уровня производительности.

Больше подробностей о производительности VMware vSphere 7 вы найдете в документе "What’s New in Performance for VMware vSphere 7?".

Компания VMware обещала большие новости о своем пакете решений vRealize True Visibility и вот недавно их объявила: теперь 19 менеджмент паков для вычислительных ресурсов и хранилищ доступны для всех пользователей продукта vRealize Operations. Также произошли некоторые изменения в самом пакете vRealize True Visibility Suite, а также были выпущены новые модули vRealize True Visibility Technology Modules, лицензируемые на базе метрик.

1. Management Packs для вычислительных ресурсов и хранилищ.

Теперь пользователи vRealize Operations получают доступ к 19 пакетам vRealize True Visibility Suite, которые позволяют получить доступ к глубоким метрикам, число которых превышает 1000.

Также пользователи получают новые детализированные дэшборды и статистики в реальном времени, которые помогают решать проблемы на всех уровнях оборудования.

Вот пример дэшборда, который отображает состояние дисковых массивов от разных вендоров в едином представлении Operations:

В данном случае удобно, что массивы представлены на одном экране с соответствующими Scoreboards, которые легко сравнивать между собой.

Все менеджмент паки vRealize True Visibility для Operations доступны по этой ссылке. А о том, как их устанавливать, вы можете узнать из большой серии обучающих видео, доступной на YouTube.

Вот ссылки на все менеджмент паки, которые вы можете использовать:

Также на ресурсе VMware Code доступны примеры дэшбордов, которые можно использовать в своем производственном окружении.

2. Изменения в пакете vRealize True Visibility Suite.

Издания vRealize True Visibility Suite Advanced и Enterprise были немного переработаны, чтобы соответствовать ожиданиям пользователей. Теперь Management packs перемещены из категории "Connectors", а менеджмент пак ServiceNow перемещен в vRealize True Visibility Suite Advanced. Вот наглядное представление изменений:

Если у вас есть издание vRealize True Visibility Suite Advanced, то вы можете уже сейчас загрузить менеджмент паки с VMware Customer Connect. Также можно ознакомиться с документацией по этим продуктам.

3. Новые модули vRealize True Visibility Technology Modules

Для тех пользователей, которые хотят расширить возможности своей инфраструктуры мониторинга за счет модулей vRealize True Visibility Technology Modules, теперь есть возможности добавить их из разных категорий: Connectors, Network, Virtualization/Containers, Database и Applications. Каждый из модулей лицензируется на базе метрики, определенной для данной категории (по числу объектов, устройств, виртуальных машин и т.п.).

Вот так выглядит полная экосистема доступных модулей:

Скачать 60-дневную пробную версию vRealize True Visibility Suite можно по этой ссылке.

В начале осени, в рамках прошедшей конференции VMworld 2021 Online, компания VMware представила свое виденье развития концепции виртуализации и агрегации хранилищ корпоративных инфраструктур - Federated Storage Platform (FSP).

Проблема современного подхода к организации хранилищ состоит в том, что аппаратные комплексы в датацентре представлены разными моделями, производителями, а также поколениями в рамках одной продуктовой линейки. Ввиду этого администраторам приходится разрабатывать набор административных регламентов по обслуживанию жизненного цикла таких хранилищ - ввод в эксплуатацию, развертывание новых сервисов, обеспечение высокой доступности и план по изменению емкостей - вывод устаревших систем и расширение существующих емкостей. Ко всему этому добавляются Day-2 Operations и обеспечение безопасности хранения данных виртуальных и физических сред.

Как итог - корпоративная инфраструктура предприятия не может обеспечить те же преимущества, что и унифицированная облачная среда, которая избавляет администраторов от заботы об оборудовании и, в частности, хранилищах.

Проблему отчасти решает подход к организации гиперконвергентной инфраструктуры (Hyperconverged Infrastructure, HCI), например, концепция HCI Mesh. Но этого было недостаточно, и VMware запустила радикальную инициативу - Federated Storage Platform (FSP) - решение, которое приведет к унификации операций онпремизных и облачных сред в плане хранилищ за счет их виртуализации и агрегации.

С помощью VMware FSP можно будет управлять любым числом хранилищ разных вендоров, с которыми работает любое количество управляющих серверов vCenter:

Здесь будет 2 ключевых сущности:

• Common volumes - это новый слой представления ресурсов хранения от гетерогенных кластеров vSAN, томов vSphere Virtual Volumes дисковых массивов, а также NFS-массивов. Все это будет объединено на уровне пулов.
• Data center control plane - новый слой управления инфраструктурой хранения на базе эластичных пулов с возможностью полного доступа к имеющимся емкостям. Все это позволит видеть ресурсы хранения как в облаке, безотносительно имеющихся моделей массивов и топологий.

FSP будет полностью интегрирован в уже имеющимся механизмом политик хранения SPBM (vSphere Storage Policy Based Management), предоставляя гибкие пулы хранения для уровня приложений на базе их потребностей. Платформа VMware vSphere будет выступать как один из потребителей ресурсов в рамках этой концепции.

Для обеспечения различных уровней сервиса будут работать расширенные политики FSP, такие как квоты на емкости и ограничения по производительности, чтобы обеспечить ярусность хранения и работы с данными.

В рамках FSP процесс добавления или списания хранилищ будет бесшовным, то есть не вовлекать физическую коммутацию, которая будет выводиться за рамки процесса управления единым пулом хранилищ. Например, FSP может автоматически обнаружить новое уже подключенное хранилище, после чего добавить его в общий federated пул и начать балансировку нагрузок посредством VMware vSphere Storage vMotion.

Сейчас администраторам приходится вручную выполнять операции SVMotion для ввода новых хранилищ в эксплуатацию и их вывода, а FSP будет делать все это автоматически в "lazy"-режиме, чтобы обеспечивать уровень производительности виртуальной среды.

FSP будет интегрирована с драйвером vSphere CSI в Kubernetes, а также технологией CNS (Cloud Native Storage). Разработчики смогут потреблять дисковые емкости в рамках классов через FSP, а администраторы получать полную видимость использования таких хранилищ на уровне всего датацентра.

Сейчас решения VMware vSphere with VMware Tanzu и TKG-S VMware Tanzu Kubernetes Grid могут развертывать рабочие нагрузки в рамках пространств имен кластера, а FSP даст возможность развернуть приложения на любом хранилище в любом кластере на базе любых доступных политик.

Сейчас с помощью x-vMotion виртуальную машину можно перемещать между кластерами и разными инфраструктурами vSphere. FSP расширит эти возможности, позволяя виртуальным машинам и контейнеризованным приложениям свободно "путешествовать" между кластерами, инфраструктурами и пространствами хранения - при этом под полным контролем управляющего слоя.

Получить больше информации об инициативе можно из записи этой ссессии с прошедшего VMworld 2021 Online: VMware’s vision for storage and data in a multi-cloud world.

Этой осенью мы писали о новых возможностях флагманской платформы виртуализации компании VMware - vSphere 7 Update 3 и Update 3a. При этом мы забыли рассказать о новой версии платформы для создания отказоустойчивых хранилищ VMware vSAN 7 Update 3. Сегодня мы закроем этот пробел.

Итак, вот какие новые возможности были добавлены в VMware vSAN 7 Update 3:

1. Cluster Shutdown

Эта функция позволяет вам погасить все хосты кластера для проведения обслуживания, даже в том случае, если они исполняют серверы vCenter. Для начала процедуры выключения хостов нужно выбрать пункт "shutdown cluster" из контекстного меню кластера и запустить двухшаговый мастер.

На первом этапе пройдут предпроверки, которые убеждаются в том, что в данный момент нет активных задач ресинхронизации, отсутствуют хосты в режиме обслуживания, служебные ВМ выключены и другое:

2. Поддержка vLCM для виртуального модуля Witness Appliance

Теперь жизненной цикл виртуальной машины Witness Appliance в кластере можно обслуживать с помощью vSphere Lifecycle Manager (делать апгрейд и прочее).

3. Функции Skyline Health Correlation

С помощью возможности Skyline Health Correlation пользователи, которые видят множество срабатывающих в кластере алармов, понимают, что им нужно сделать. В vSAN 7 U3 можно понять корреляцию между событиями и сделать вывод о наиболее вероятной проблеме. Далее уже можно приступать к поиску корневой причины.

4. Возможность IO Trip Analyzer

IO Trip Analyzer - это средства, которые позволяют посмотреть информацию о задержках (latency) на каждом из уровней в форме диаграммы. Вот небольшой обзор этого инструмента от Дункана Эппинга:

5. Вложенные домены отказа Nested Fault Domains для 2-узловых кластеров

Домены Nested Fault Domains для 2-узловых кластеров предназначены для пользователей, которые хотят получить устойчивую к отказам конфигурацию на базе всего двух хостов ESXi. Для этого нужно иметь как минимум 3 дисковых группы на хост на каждом из узлов, после чего создается массив RAID-1 между этими двумя хостами, а также RAID-1 внутри каждого из хостов (можно также использовать RAID-5, если у вас достаточное количество дисковых групп). Если упадет один из хостов ESXi, а потом и еще один из дисков на выжившем хосте - то виртуальные машины все равно продолжат работать.

6. Функции Enhanced Stretched Cluster Durability

Мы уже писали о возможностях Enhanced Data Durability для кластеров vSAN, позволяющих еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.

Теперь функции Enhanced Stretched Cluster Durability позволяют обработать ситуацию, когда отказывает одна из площадок растянутого кластера, а после этого и компонент Witness сторонней площадки. В этом случае ВМ растянутого кластера ранее оказывались недоступны, потому что последовательно происходил отказ двух из трех компонентов RAID растянутого кластера. В случае одновременного отказа сайта и компонента Witness происходила блокировка второго сайта и для обеспечения консистентности данных и защиты от ситуации Split Brain. Теперь же происходит обработка и ситуации последовательного отказа сайта и Witness.

В этом случае обеспечивается строгая консистентность данных виртуальных машин, так как упавший сайт может лежать достаточно долго.

Если все дисковые объекты виртуальных машин сохранились на работающей площадке, то даже в случае недоступности Witness все виртуальные машины продолжат свою нормальную работу. Более подробно об этой возможности Дункан рассказал вот тут.

7. Механизм Access Based Enumeration для SMB-шар через службы vSAN File Services

До vSAN Update 3, если пользователь имел доступ к SMB-шаре, то он мог просматривать список всех ее каталогов. Теперь же с помощью Access Based Enumeration для служб vSAN File Services пользователь видит только назначенные ему папки.

Посмотреть полный список новых возможностей VMware vSAN 7 Update 3 можно в Release Notes, а загрузить продукт можно по этой ссылке.

Также в комментариях поделились полезным видео от русской команды VMware, где рассказывается не только о новых возможностях vSAN 7 Update 3, но и о нововведениях vSphere и Tanzu в новом апдейте:

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Сегодня мы поговорим о том, как настраивать аутентификацию доступа к хранилищам через протокол CHAP в решении StarWind Virtual SAN...

Вчера мы писали о новых возможностях анонсированного недавно обновления платформы виртуализации VMware vSphere 7 Update 3. Сегодня мы чуть детальнее разберем возможности обновленного продукта, касающиеся хранилищ виртуальных машин. Нововведения были сделаны в следующих областях:

1.Поддержка NVMe over TCP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании.

2. Увеличение числа хостов на один датастор

У VMware есть какое-то количество клиентов, которые достигли предыдущего лимита в 64 хоста ESXi на одно виртуальное хранилище VMFS или NFS. В Update 3 этот лимит был расширен до 128 хостов. Надо понимать, что к лимитам кластера это число не имеет отношения - это только число хостов, которые могут одновременно использовать датастор.

3. Affinity 3.0 и поддержка CNS

В vSphere 7 компания VMware обновила Affinity Manager до версии 2.0, который уменьшает затраты на первые операции записи для thin и lazy thick дисков. В Affinity 3.0, который вошел в этот релиз, появилась поддержка персистентных томов Cloud Native Storage (CNS), которые также называются FCD (First Class Disks). Также добавлена поддержка большего числа хостов ESXi на один кластер.

4. Пакетные снапшоты томов vVols

В этом обновлении vSphere была существенно улучшена процедура обработки большого одновременного количества снапшотов томов vVol, которая может происходит в рамках процессов обслуживания хранилищ и резервного копирования. Операции снапшотов группируются и обрабатываются в рамках пакетного процесса, уменьшается общее число операций, поэтому в итоге нагрузка на хранилища уменьшается.

Более подробно обо всех новых возможностях VMware vSphere 7 Update 3 в отношении хранилищ рассказано в этой статье.

На днях компания VMware объявила о релизе новой версии решения Object Storage Extension 2.1 (OSE). Напомним, что это фремворк для поддержки хранилищ S3 в инфраструктуре сервис-провайдеров, которые работают на базе VMware Cloud Director. Год назад мы упоминали о выпуске версии 2.0, а сегодня расскажем, что нового там появилось за это время.

Итак, новые возможности Object Storage Extension 2.1:

1. Резервное копирование и восстановление по запросу для Kubernetes (оно же K8s B&R)

VMware Cloud Director Object Storage Extension теперь имеет встроенные возможности Kubernetes Backup & Restore (K8s B&R), которые доступны непосредственно в VMware Cloud Director. Теперь облачные провайдеры могут защищать не только виртуальные машины, но и рабочие нагрузки контейнеризованных приложений. Возможности K8s B&R построены на базе решения Velero, которое использует S3-протокол для хранения резервных копий, чтобы защитить данные на персистентных томах.

Резервное копирование изначально поддерживает инфраструктуру большого количества клиентов (multi-tenancy), которые работают с кластерами TKG, CSE-кластерами и отдельными K8s-инсталляциями под управлением Container Service Extension 3.0. Также при бэкапе используется end-to-end шифрование.

Подробнее о новых функциях резервного копирования рассказано тут.

2. Доступ к облачным политикам хранения Cloudian

Политики объектных хранилищ Cloudian позволяют обеспечивать защиту и распределение хранилищ между потребителями в рамках организации. С помощью простых правил облачные провайдеры могу дать пользователям возможности создавать свои бакеты и объекты. Начиная с версии OSE 2.1, клиенты, которые используют Cloudian, могут создавать кастомные политики хранилищ непосредственно из OSE. Более подробно об этом написано тут.

3. Улучшенная синхронизация бакетов и вывод объектов

Для клиентов с несколькими площадками бакеты теперь агрегируются в рамках одного представления в консоли VMware Cloud Director. Облачные провайдеры могут наблюдать за статусом синхронизации бакетов своих клиентов. Также на глобальном уровне доступна опция синхронизации бакетов, которую могут включить администраторы сервис-провайдера, чтобы убедиться, что все мультисайтовые бакеты синхронизированы (включение этой фичи можно также поставить в планировщик). Более подробно об этом тут.

4. AWS S3 Archived Object Restoration

Amazon S3 требует, чтобы каждый объект был ассоциирован с классом хранилищ в зависимости от варианта использования. Из доступных четырех классов пользователи и администраторы облачных провайдеров могли получать доступ к Standard и Intelligent классам. Теперь же клиенты могут получить доступ к классам Glacier и Glacier Deep (но сначала нужно включить функцию restore для объектов). Более подробно VMware рассказала об этом здесь.

5. Управление на базе ролей (Role-based Access Control, RBAC)

Теперь можно использовать кастомные роли, чтобы назначить их пользователям клиентов для управления объектами vApps, Catalogs и Kubernetes B&R. В новой версии есть встроенный список удобного выбора пользовательских прав, с помощью которого администраторы облачных провайдеров (или администраторы клиентов) могут просто ограничить возможности отдельных пользователей. Детально об этом написано тут.

6. Улучшенные функции управления для ресурсов VMware Cloud Director - vApps, VM, Catalogs

В прошлой версии OSE администраторы имели ограниченную видимость при импорте и экспорте истории vApp. Теперь же вся история доступна в виде полного списка происходивших событий. Также в интерфейсе произошло несколько изменений - новое меню для создания и восстановления виртуальных приложений vApp теперь бесшовно интегрировано в консоль Cloud Director. Подробнее об этом можно почитать по этой ссылке.

Скачать VMware Object Storage Extension 2.1 можно вот тут. Есть также несколько интересных документов и материалов по продукту:

• Release Notes
• Upgrading to VMware Cloud Director Object Storage Extension 2.1
• OSE 2.1 Solution Overview
• OSE 2.1 Reference Design Whitepaper
• OSIS Development Guide

Многие администраторы VMware vSphere в крупных компаниях рано или поздно сталкиваются с необходимостью создания кластеров из виртуальных машин, например, для использования технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) или для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance. При использовании кластерных решений необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли...

Весной этого года мы рассказывали о новых возможностях продукта VMware Cloud Disaster Recovery, который позволяет производить кросс-облачное восстановление виртуальных сред. Одним из самых страшных DR-сценариев для администраторов является поражение инфраструктуры программой-вымогателем (ransomware), которая зачастую блокирует компьютеры, а данные их дисков зашифровывает.

Традиционная инфраструктура бэкапа в этом случае может оказаться малоэффективной - ведь сложно определить момент, когда произошло инфицирование компьютеров/виртуальных машин, а также трудно быстро поднять десятки и сотни систем, ну и тяжело запустить там все процедуры проверки.

Вот какие моменты важны при борьбе с массовой атакой посредством ransomware:

• Возможность иметь достаточное количество копий назад во времени, чтобы выбрать точку чистой от вредоносного ПО системы.
• Возможность мгновенно включить ВМ для проверки, не запуская длительный процесс восстановления. Потому что таких виртуальных машин может быть очень много.
• Обеспечение сохранности и неизменности самих бэкапов - надо сделать так, чтобы зараженные машины не зашифровали сами резервные копии - ведь тогда нечего будет и восстанавливать.
• Нужно регулярно убеждаться, что бэкапы не повреждены (например, вследствие какого-то бага).
• Ну и все процедуры по восстановлению не должны стоить космических денег, что может разорить компанию.

В ответ на эти требования компания VMware разработала облачную файловую систему Scale-out Cloud Filesystem (SCFS), которая позволяет хранить готовые к восстановлению резервные копии ВМ, избегая больших затрат.

Делается это за счет комбинации в одном хранилище двухъярусной архитектуры - для хранения резервных копий и для исполнения нагрузок. Облако EC2 с локальными NVMe-хранилищами используется для обеспечения работы высокопроизводительных нагрузок (cache-tier), а S3-хранилища используются для больших объемов данных (capacity tier).

Это позволяет независимо масштабировать ресурсы для увеличения производительности и емкости. Часть cache-яруса используется для обработки входящих данных по резервному копированию, чтобы обеспечить баланс потока резервного копирования (backup-mode) и исполнения нагрузок. Когда нужно приступить к восстановлению (recovery-mode) ярус кэша может быть расширен, чтобы виртуальные машины запускались напрямую с этой файловой системы. То есть, такой дизайн файловой системы позволяет быстро переключаться между режимами backup-mode и recovery-mode.

Этот подход основан на Log-Structured Filesystem (LFS), файловой системы, которая была предложена еще в 1992 году одним из основателей VMware Менделем Розенблюмом. Она основывается на идее, что устройства хранения (HDD, SSD, S3) не так производительны в случайных операциях, как в последовательных, а sequential writes как раз удобно использовать для такой структуры хранения бэкапов. Идея LFS в том, чтобы сохранять данные изменений файловой системы в виде лога, а позже проводить его очистку.

Эти же техники использует VMware Cloud Disaster Recovery в облаке S3. Как видно из картинки, все входящие данные бэкапов разбиваются на большие сегменты в 10 МБ, которые последовательно записываются на хранилище как объекты S3 на высокой скорости. Данные хранятся в виде лога, то есть не перезаписывают прошлые данные. Это позволяет избежать ситуации, когда резервные копии виртуальных машин перезаписываются уже инфицированными бэкапами.

Для такой структуры необходим эффективный механизм по работе с указателями на данные, чтобы быстро позиционироваться на нужных блоках при запуске ВМ напрямую из резервной копии. Для этого VMware использует криптохэши на базе контента, которые невозможно подменить со стороны вредоносного ПО. Эти криптохэши организованы по структуре дерева (см. подробнее тут), а сами бэкапы недоступны для модификации из внешнего мира, то есть самой производственной среды.

При восстановлении сами бэкапы тоже не трогаются - создается копия объектов бэкапа и виртуальная машина сразу же запускается с использованием этих данных. Работает это практически мгновенно, причем неважно сколько машин запускается в рамках задачи.

Также в SCFS есть встроенный механизм проверки целостности резервных копий на ежедневной основе, что позволяет избежать ситуации, когда нужно восстанавливать системы, а данные повреждены.

Начать изучение платформы VMware Cloud Disaster Recovery можно с этой странички.

Дункан Эппинг написал интересную заметку о том, как работают Storage Rules для политик хранения виртуальных машин в кластерах VMware vSAN (VM Storage Policies).

В большой инфраструктуре или, например, в топологии HCI Mesh часто встречается такая ситуация, когда некоторые кластеры построены на базе гибридных хостов (SSD+HDD), а некоторые на базе All-Flash оборудования. Также в зависимости от типа железа, эти кластеры могут предоставлять различные сервисы (например, шифрование или дудпликацию), которые могут использовать виртуальные машины.

Когда вы создаете VM Storage Policy в решении VMware vSAN, то, начиная с vSAN 7.0 U2, вы можете задать Storage Rules для данной политики на отдельной вкладке:

Эти настройки влияют вот на что: когда вы назначаете политику хранения виртуальной машине, у которой, например, выбран пункт "data-at-rest encryption" в качестве поддерживаемых сервисов хранилищ, то в качестве совместимых будут показаны только те хранилища, у которых реально предоставляется этот сервис со стороны оборудования. То есть эта вкладка нужна для того, чтобы обеспечить исполнение требований со стороны железа по сервисам перечисленным здесь (а именно: шифрование, компрессия, компрессия+дедупликация, размещение на гибридном/All-Flash хосте) для виртуальных машин, которым назначается политика.

То есть, Storage Rules - это поддержка тех сервисов, которые должны быть уже включены на ваших датасторах. Они работают именно на уровне vSAN Datastore и не применяются к сервисам данных (data services) на базе виртуальной машины или VMDK-дисков.

Недавно мы писали о новом продукте StarWind SAN & NAS от лидера в сфере программно-аппаратных хранилищ под виртуализацию - компании StarWind. Он предназначен для создания программных хранилищ на основе серверов с установленным там гипервизором.

Ну а на днях вышло еще одно новое решение - StarWind Backup Appliance. Оно, как можно догадаться, предназначено для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе хранилища NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.

Теперь бэкап на такое хранилище можно делать в любое время и без влияния на работу приложений и служб. За счет использования этого комплекса время резервного копирования у вас снизится минимум в 2 раза.

Более того, в случае сбоя вы сможете мгновенно восстановить виртуальные машины и файлы напрямую из резервной копии, обеспечив наилучшие показатели RPO и RTO по сравнению с традиционными решениями.

Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.

Высокая производительность и надежность решения достигается как за счет технологии NVMe, так и за счет отделения и изоляции сервисов резервного копирования от производственных данных. При этом сервисы бэкапа StarWind BA нагружают системные ресурсы только тогда, когда начинают выполнять задачу резервного копирования.

Важный момент, который стоит отметить - продукт Backup Appliance от StarWind поддерживается со стороны ProActive Premium Support, а значит, что ваша инфраструктура резервного копирования будет работать 24x7, даже когда вы в отпуске или спите.

Естественно, данные, находящиеся на хранилище резервных копий, надежно защищены с помощью технологий RAID и полностью отделены от сервисов, непосредственно реализующих резервное копирование. Ну а приятный бонус - это то, что вы можете выбрать один из следующих гипервизоров на модуле StarWind BA:

• Microsoft Hyper-V версий 2016, 2019 или 2022
• VMware vSphere версий 6.5, 6.7 или 7.0

На данный момент доступны 2 модели Backup Appliance (BA 30 и BA 60):

Как мы видим, обе модели представляют собой одноюнитовые серверы с 30 или 60 ТБ емкости (это полезная емкость после создания RAID) и 64 ГБ оперативной памяти на борту.

В качестве протоколов доступа к данным поддерживаются следующие:

• iSCSI
• SMB3
• NFSv4.1
• NVMe-oF

Ну и главное - в качестве ПО для резервного копирования используется лидирующий в отрасли продукт Veeam Backup and Replication V10 и V11. Тут можно быть спокойным - он работает надежно и быстро. В качестве системы мониторинга и отчетности можно использовать решение Veeam ONE.

Больше информации о решении StarWind Backup Appliance можно получить на этой странице. Живое демо продукта вы можете запросить вот тут.

На сайте проекта VMware Labs обновилась очередная интересная утилита Storage Performance Tester, которая позволяет провести тестирование хранилищ в один клик на сервере VMware ESXi, получив метрики IOPS, latency и CPU cycles per I/O. В новой версии появилась поддержка адаптеров vnvme, а также исправления ошибок для ESXi 6.7.

С помощью данного средства можно автоматизировать шаги проведения тестирования, которые включают в себя развертывание кастомизированной ВМ, запуск нагрузки по вводу-выводу внутри нее и, собственно, функции по анализу результата тестирования производительности.

Результаты для полученных метрик выводятся в графическом интерфейсе в виде диаграмм и комментариев к ним:

Самое приятное - это то, что утилита запускается одной командой, после чего пользователь получает итоговый результат. Выглядит это так:

#./sperf.py HOSTNAME -d DatastoreName

Данное средство можно использовать как для решения проблем с действующей инфраструктурой хранилищ, так и для выяснения максимальных параметров производительности только что купленного железа (диски, контроллеры, компоненты сети хранения данных).

Ну и видео о том, как это все работает:

Для запуска Storage Performance Tester вам потребуется:

• Python 3
• sshpass
• 2 ГБ свободного пространства на диске
• Linux-окружение (ядро не старше 2.6.31)

Скачать Storage Performance Tester можно по этой ссылке.

При поддержке Антона Гостева сотрудники отдела маркетинга компании Veeam Software (а это, напомним, производитель средств для резервного копирования виртуальных инфраструктур номер 1) запустили конкурс «Обгони Гостева».

Неофициально конкурс стартовал внутри команды Veeam в феврале этого года. В своей рассылке на форуме Гостев рассказал об установке системы резервного копирования Veeam, которая показала максимальную производительность, достигающую 11.4 ГБ/с. Коллеги делились цифрами, которые встречали в своей практике, и искали новые данные, которые побьют цифры Гостева. Теперь в Veeam решили сделать этот конкурс публичным - ищется самая быстрая инфраструктура резервного копирования Veeam в России!

Участвуйте и расскажите о конкурсе коллегам. Перед участием прочитайте ответы на вопросы об условиях конкурса. Самые интересные случаи Veeam соберет и опубликует в статье. Три самых быстрых результата получат призы:

• Электросамокат XIAOMI
• Проектор Xiaomi Mi Smart
• Умная колонка Яндекс.Станция

Размещать результаты можно в Facebook или Twitter с хештегом #BeatTheGostev. Публикации с большим количеством лайков получат также шанс выиграть дополнительный секретный приз!

Конкурс продолжится до 30 сентября включительно, после чего будут подведены итоги. Кстати, скорость 11,4 ГБ/с для системы резервного копирования не является минимальным требованием для участия в конкурсе.

Участвовать!

Компания VMware уже несколько недель назад сделала доступным каталог сессий предстоящего VMworld 2021. Некоторое время назад мы уже писали про изменения, которые произойдут в онлайн-конференции, а сегодня немного расскажем о самом каталоге будущих выступлений.

Сейчас в списке 850 сессий (может быть, будет больше), искать можно как по ключевым словам, так и по различным аспектам докладов (для кого они, о каких продуктах, уровень сложности материала и прочее).

А вот список самого интересного от Дункана Эппинга - глубокие технические сессии от известных блоггеров и сотрудников VMware:

• Project Monterey: Present, Future and Beyond [MCL1401] by Sudhanshu Jain and Simer Singh
  
• What Is the Future of Cloud and On-Premises Storage and Availability? [MCL2590]
• Make Sustainable Choices for Product Innovation, Operations: What Can I Do? [IC2794]
• Core Storage Best Practices Deep Dive [MCL2071]
  
• Security Deep Dive and Emerging Capabilities in VMware Cloud on AWS [SEC1362]
• VEBA Revolutions – Unleashing the Power of Event-Driven Automation [CODE2773]
• VDI Nerdfest 2021: Demos That Make Admins Drool [EUS1289]
  
• Extreme Performance Series: Performance best practices [MCL1635]
• 60 Minutes of Non-Uniform Memory Access (NUMA) 3rd Edition [MCL1853]
• Best Practices for Running AI Workloads in VMs on VMware vSphere [VI1459]
• The Future of VM Provisioning – Enabling VM Lifecycle Through Kubernetes [APP1564]
• The Evolution of Intelligent Edge and Electrical Grid Modernization [VI1455]
• Upskill Your Workforce with Augmented and Virtual Reality and VMware [VI1596]
• Automating Ransomware Remediation with the VMware Carbon Black Cloud SDK [CODE2782]
• Migration in Action with Google Cloud VMware Engine [MCL1764]

В общем, в начале октября будет точно что посмотреть и послушать!

Cormac Hogan, известный специалист в области виртуальных хранилищ на платформе VMware vSphere, выпустил интересное видео об использовании постоянных томов (Persistent Volumes) в качестве файловых шар для кластеров Kubernetes:

В качестве бэкенда таких томов используются файловые шары кластеров VMware vSAN, которые позволяют администраторам Kubernetes контролировать их использование со стороны инфраструктуры контейнеризованных приложений. В видео рассказано о том, как предоставлять права доступа (read only, read/write) на базе параметров сетей, которые получают доступ к томам. Также у Кормака есть детальная статья о том, как эти права доступа настраивать.

Из видео вы узнаете, как шаг за шагом настраивать доступ к томам через конфигурационный файл CSI-драйвера и контролировать сетевой доступ в томам через службы vSAN File Services.

Дункан Эппинг обратил внимание на довольно частую проблему у пользователей VMware vSphere 7, которые делают апгрейд с Update 1 на Update 2. Если вы используете подключение к хранилищам по iSCSI и рандомные имена IQN для инициаторов, то после апгрейда хранилища могут перестать быть доступными, если вы используете контроль доступа на базе IQN.

Проблема проявляется, только если вы создавали подключения по iSCSI именно в vSphere 7 Update 1 на свежей установке. Причина проста - изменился стандарт случайного именования IQN для iSCSI-инициаторов. Если для Update 1 он выглядит так:

iqn.1998-01.com.vmware:labesx06-4ff17c83

То для Update 2 уже так:

iqn.1998-01.com.vmware:labesx07:38717532:64

Соответственно, после апгрейда имя инициатора у вас изменится. Чтобы сделать хранилища iSCSI вновь доступными, надо пойти на дисковый массив или виртуальный модуль (Virtual Appliance) и вбить туда новое имя инициатора. Либо вы можете сделать имя инициатора вручную и вбить его также и на массиве для нужных LUN.

Кстати, при апгрейде с версии vSphere 6.7 или vSphere 7 сразу на Update 2 проблема не возникает, так как настройки iSCSI корректно переезжают сразу в configstore.

Чтобы изменить имя iSCSI-адаптера, можно использовать вот эту команду, чтобы это имя получить:

$ esxcli iscsi adapter get -A vmhba67

Вывод будет, например, таким:

vmhba67
Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

И потом вот эту команду, чтобы задать новое имя:

$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

Также можно это сделать и с помощью PowerCLI-сценария (подробнее тут):

Get-VMHost |
ForEach-Object -Process {
    $HostHBA = $_ | Get-VMHostHba -Type iScsi | Select-Object Name,IScsiName
    $esxcli = get-esxcli -v2 -vmhost $_
    $CLIARG =  @{
        adapter = $HostHBA.Name
        name = $HostHBA.IScsiName
        skipifsessionactive = $false
        }
    $esxcli.iscsi.adapter.set.Invoke($CLIARG)
write-host "Setting host " $H  "adapter"  $HostHBA.Name "with IQN" $HostHBA.IScsiName
    }

Весной этого года компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Основные улучшения знает большинство администраторов, так как об этом писали достаточно подробно. Но есть и несколько небольших, но важных изменений, знать про которые было бы очень полезно. Давайте на них посмотрим...

Некоторое время назад мы писали о First-Class Disks (FCD), которые были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes.

При создании профиля хранилищ вы можете указать тип диска как FCD:

В VMware vSphere 7 Update 2 для FCD появилась поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.

В VMware vRealize Automation версии 8.2 появилась поддержка First-Class Disks (FCD), что открывает большие возможности по автоматизации операций при управлении такими хранилищами. Это функции улучшаются с каждым релизом vRA.

Eric Sloof написал небольшую заметку об использовании таких дисков с vRealize Automation. Одно из преимуществ дисков FCD - это возможность создавать их снапшоты независимо от каких-либо виртуальных машин.

При создании и редактировании описания профиля хранилищ в VMware vRealize Automation вы можете указать поддержку в дисков FCD или обычных дисков в storage profile:

Также через API в vRealize Automation вы можете получить доступ к операциям Create, Edit, Delete и List для таких дисков. Также в рамках рабочих процессов в Automation доступны и day-2 операции, такие как добавление диска, привязка/отвязывание и изменение размера.

Для снапшотов диска также доступны операции управления их жизненным циклом. Так что администраторы теперь могут придумывать и автоматизировать рабочие процессы с постоянными виртуальными дисками FCD для самых разных задач.

Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...

Компания VMware обновила пакет драйверов Community NVMe Driver for ESXi до версии 1.1 на сайте проекта VMware Labs. Эти драйверы были выпущены в начале года, а сейчас вышло их обновление с поддержкой VMware ESXi 7.0.

Данный Fling представляет собой пакет нативных драйверов для ESXi, которые позволяют поддерживать различные хранилища на базе технологии NVMe. Надо понимать, что community-драйверы не входят в официальный список поддержки VMware HCL, поэтому использовать их можно только в тестовых средах.

Драйверы теперь поддерживают VMware ESXi 7.0 или более поздние версии гипервизора для NVMe-хранилищ не от Apple. Пока список поддерживаемых устройств такой:

Для хранилищ Apple SSD пока поддерживается только ESXi 6.7 до версии Patch 03 (Build 16713306). Более новые версии гипервизора с NVMe-устройствами Apple, к сожалению, не работают. Пока драйверы поддерживают Apple 2018 Intel Mac Mini 8.1 и Apple 2019 Intel Mac Pro 7.1, причем подключение портов Thunderbolt 3 не поддерживется (ESXi может выпасть в PSOD).

Драйверы поставляются в виде VIB-пакета, установить который можно командой:

Скачать Community NVMe Driver for ESXi 1.1 можно по этой ссылке.

Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.

Основные темы документа:

• Что такое снапшоты
• Какие есть форматы снапшотов
• Описание тестового окружения и рабочих нагрузок
• Результаты тестирования производительности
• Выводы по этим результатам

Итак, для тестирования использовались следующие рабочие нагрузки:

• FIO (стандартный тест производительности ввода-вывода)
• JVM (бенчмарк SPECjbb 2015)
• OLTP database (тест HammerDB)

Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:

1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):

В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.

2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:

3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:

4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:

Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.

5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:

Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.

Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:

При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):

Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:

Итак, очевидные выводы:

• Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
• Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
• Хранилищам VVol все равно на снапшоты, производительность не падает.
• Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
• При удалении снапшотов производительность ВМ возвращается к исходному уровню.

На сайте проекта VMware Labs обновилась утилита HCIBench 2.6, которая до этого обновлялась осенью прошлого года. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.

Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду средству Vdbench, содержащую инструкции о том, какие действия необходимо выполнить в кластере хранилищ. Это может вам пригодиться, например, когда вы хотите убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Давайте взглянем на новые возможности HCIBench 2.6:

• Сервер tomcat обновлен до версии 8.5.68
• Поддержка IPv6 для сетей ВМ и Management Network - как для DHCPv6, так и для link-local mode
• Поддержка режима развертывания multi-writer disk
• Улучшенная пре-валидация за счет перехода на govc
• Поддержка спецификации read/write io_limit для fio
• Исправлена ошибка при запуске в инфраструктуре VMC
• Улучшена система сбора диагностических бандлов в режиме отладки vSAN

Скачать VMware HCIBench 2.6 можно по этой ссылке.

Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.

Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:

Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:

NETDUMPER_DIR_MAX_GB 

Максимальный его размер может составлять 10GB.

После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:

service-control --restart vmware-netdumper

На vCSA 6.7 двумя:

service-control --stop vmware-netdumper
service-control --start vmware-netdumper

Вильям Ламм написал интересную статью про USB-устройства на хосте VMware ESXi, когда нужно использовать некоторые устройства как хранилища, а некоторые - для проброса в виртуальные машины. При этом, в рамках данной методики, не нужно останавливать USB Arbitrator Service на хосте.

Итак, для начала выводим список доступных USB-интерфейсов на сервере:

esxcli hardware usb passthrough device list

У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):

Для второго устройства можно отключить именно функции проброса USB (passthrough), чтобы устройство не могло быть презентовано виртуальной машине. Для этого выполняем такую команду:

esxcli hardware usb passthrough device disable -d 2:7:90c:1000

После этого будет вот такая картина:

Далее уже можно подключить это устройство хранения к хосту ESXi, чтобы использовать его для создания VMFS-томов. Процедура описана вот тут, посмотрим на нее вкратце.

Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:

esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1

Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:

vdq -q

Затем создаем переменную с именем устройства, например:

DEVICE_NAME="t10.JMicron_Generic_________0123456789ABCDEF"

Затем выполняем следующие команды для создания SATP-правила и перезагрузки устройства, которое подцепится как SSD-хранилище:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device=${DEVICE_NAME} --option=enable_ssd

esxcli storage core claiming unclaim --type device --device=${DEVICE_NAME}

esxcli storage core claimrule load

esxcli storage core claimrule run

Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:

Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.

Создаем переменную с полным путем к устройству:

DEVICE_PATH="/vmfs/devices/disks/t10.JMicron_Generic_________0123456789ABCDEF"

Далее выполняем команду, которая разметит наш том как VMFS:

partedUtil mklabel ${DEVICE_PATH} msdos

END_SECTOR=$(eval expr $(partedUtil getptbl ${DEVICE_PATH} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1)

/sbin/partedUtil "setptbl" "${DEVICE_PATH}" "gpt" "1 2048 ${END_SECTOR} AA31E02A400F11DB9590000C2911D1B8 0"

/sbin/vmkfstools -C vmfs6 -b 1m -S $(hostname -s)-local-usb-ssd-datastore ${DEVICE_PATH}:1

Если все в порядке, вы увидите новый том в списке VMFS-томов в vSphere Client:

На днях компания StarWind, ведущий производитель средств для создания программно-аппаратных хранилищ под виртуализацию, выпустила новую версию своего флагманского продукта - StarWind Virtual SAN v8 for Hyper-V (build 14120). Надо отметить, что в конце марта этого года StarWind уже выпускала обновление Virtual SAN (build 14033), поэтому ниже мы расскажем о новых возможностях обеих версий.

Итак, что нового появилось в StarWind Virtual SAN v8 for Hyper-V в этом году:

1. Компоненты VTL и Cloud Replication

• Поддержка Microsoft Azure - добавлена опция по загрузке файлов в Archive tier напрямую, без необходимости сначала добавлять их в Hot/Cool tier и дальнейшего перемещения в архив.
• Возможность Write Protect для виртуальных кассет.
• Минимальный размер кассеты установлен в 50 МБ.
• Режим VTL file operation mode изменен на принудительное закрытие неиспользуемых файлов. Если в работе слишком много частей виртуальных кассет, то много открытых файлов могло привести к исчерпанию ресурсов. Изменить это поведение теперь можно в параметре closedatafiles в конфиге StarWind.cfg.
• Исправлена ошибка при восстановлении кассет, разделенных на части, из облака (некоторые части могли не загружаться).
• Пофикшена ошибка в cloud replication, которая могла возникать, если установлена опция "Create new empty tapes automatically when existing tape removed from VTL for replication". Если она была включена, это могло привести к падению сервиса при создании новой виртуальной кассеты.

2. Улучшения синхронной репликации

• Исправлена ошибка с отклонением синхронизации HA-узла при перезапуске сервиса на одном из узлов (иногда процедура не стартовала автоматически).
• Исправлена ошибка, приводившая к падению сервиса в случае, если соединение с хранилищем или сетевое соединение испытывало падение производительности.
• Исправлена реализация алгоритма Node Majority failover strategy. Ранее она работала некорректно в случае, если соединение между узлами было нарушено, но только в одну сторону.
• Пофикшена процедура автоматического восстановления для трехсторонней репликации. Ранее она использовала информацию от двух из трех узлов, что некорректно для процедура auto-restore. Теперь учитывается статус от всех трех узлов.
• Поправлено некорректное поведение при операции расширения размера хранилища на узле. Это приводило к разрыву соединения для некоторых случаев, когда операции по работе с хранилищем занимали продолжительное время.
• Исправлена ошибка, которая вела к полной синхронизации вместо быстрой в некоторых случаях.
• Исправлена ошибка с обработкой IO-запросов на одном из хранилищ, приводившая к тому, что в случае зависания запроса на конфигурации с three-way репликацией происходила некорректная работа на всех трех узлах.

3. Основные улучшения

• Улучшения производительности для версии VSA (Virtual Storage Appliance).
• Исправлена проблема с закрытием сессии в случаях, когда обнаруживался критический недостаток ресурсов.
• Исправлена проблема с обработкой операции control connection close - в некоторых случаях это приводило к генерации большого числа нотификаций, а Management Console переставала отвечать.
• Исправлена процедура session close при остановке службы - теперь она не зависает в некоторых редких случаях.
• Исправлена проблема с зависанием Management Console при накатывании бесплатной лицензии на сервер без интернет-соединения.
• Было обновлено лицензионное соглашение.

4. StarWindX PowerShell Module

• Физические устройства теперь есть в общем списке устройств. Их можно использовать для экспорта с физических ленточных устройств.
• Добавлено свойство MaintenanceMode для объекта HA Device.

Загрузить пробную версию StarWind Virtual SAN v8 for Hyper-V можно по этой ссылке. Документация доступна здесь, а Release Notes - вот тут.

Отметим также, что обновился и продукт в формате виртуального модуля для платформы VMware - StarWind VSAN for vSphere (OVF Version 20210520, Version 8 build 14120). Release notes доступны тут (список улучшений там практически такой же, за исключением некоторых моментов в мартовской версии).